ILL – Interbibliothecair leenverkeer

1 Inleiding[//]

Dit document geeft workflow en achtergrond informatie met betrekking tot aanvragen voor interbibliothecair leenverkeer. Zie de help van AFO 821 voor functionele informatie en de help van AFO 822 voor parameter informatie, evenals de Preferences help voor informatie over configureren van de WebOpac.

Terminologie: Uitgaande aanvragen zijn aanvragen die geplaatst zijn door onze leners, voor materialen die niet in onze collectie aanwezig zijn. - Inkomende aanvragen zijn aanvragen die binnenkomen van een andere bibliotheek voor “onze” materialen.
Dit klinkt logisch, maar bij een uitgaande aanvraag komt er een boek bij ons binnen hetgeen verwarrend kan zijn.

In de documentatie wordt verder uitgegaan van terminologie zoals gehanteerd voor het ISOILL protocol. “Klant” is de persoon of organisatie voor wie iets wordt aangevraagd, “aanvrager” is de aanvragende bibliotheek. In sommige gevallen is afgeweken van de standaard terminologie om aan te sluiten bij verwoordingen binnen de Vubis applicatie.

1.1 Overzicht[//]

Systeem beschrijving

Er wordt een overzicht gegeven van de IBL module met de bijbehorende processen en workflow - met andere woorden, we plaatsen de module in context van het systeem.

De module voor Interbibliothecair leenverkeer is ontworpen in zowel inkomende als uitgaande IBL aanvragen te verwerken. De module is volledig geïntegreerd in de rest van het systeem, alle gerelateerde gegevens zijn waar van toepassing beschikbaar binnen het hele systeem.

Behalve voor IBL aanvragen kan de module ook gebruikt worden voor het beheer van documentleverantie aanvragen van externe gebruikers (bijv. bedrijven).

Integratie

Een aantal voorbeelden van belangrijke punten waarop het systeem geïntegreerd is:

Lenersgegevens – alle lenersinformatie voor aanvragen komt rechtstreeks uit de Vubis database – er hoeft niets apart ingevoerd te worden.

Bibliografische gegevens – als een uitgaande aanvraag wordt ingevoerd in het systeem wordt een tijdelijke titelbeschrijving aangemaakt (omdat deze per definitie niet bestaat). Bij ontvangst van het aangevraagde werk wordt een tijdelijk exemplaarrecord aangemaakt, dat gebruikt kan worden om de uitlening aan de aanvragende lener te volgen.

Het verwerken van aanvragen is volledig geïntegreerd in reguliere processen binnen de bibliotheek – wanneer bijvoorbeeld een inkomende aanvraag wordt geaccepteerd door de bibliotheek, dan kan deze met een eenvoudige handeling worden omgezet in een reservering of magazijnaanvraag zodat de normale workflow voor het onderscheppen van materialen kan worden gebruikt om een exemplaar te lokaliseren en naar de aanvragende bibliotheek te sturen.

Veel van de invulschermen hebben al default waarden en vele velden zijn optioneel. Wanneer de bibliotheek een bepaalde optie niet gebruikt, worden de bijbehorende datavelden niet getoond of aangeboden. Met andere woorden, het systeem kan ergonomisch en gebruikersvriendelijk worden ingericht.

Levering en ontvangst van aanvragen

De levering en ontvangst van aanvragen (dus niet van de werken zelf) kan geregeld worden via diverse mechanismen. De voornaamste is het ISOILL protocol (ISO 10160/10161), waarmee alle aanvragen en gerelateerde transacties elektronisch verstuurd kunnen worden tussen bibliotheken.

Maar ook het versturen en ontvangen van aanvragen tussen systemen die niet het ISOILL protocol hanteren wordt ondersteund (bijv. per e-mail of in gedrukte vorm). Deze mechanismen maken ook elektronische verzending mogelijk (tot op zekere hoogte) van andere dan ISOILL aanvragen.

Diverse andere mechanismen voor automatische verzending en ontvangst van aanvragen die geïmplementeerd zijn omvatten British Library ARTEmail, het PICA E-mail formaat en in de toekomst Impala in België.

Levering en ontvangst van het werk

De IBL moduel ondersteunt verzending van elektronische exemplaren van een werk, zoals via FTP.

The Interlibrary Loan module provides support for the transmission of electronic copies of the work, via variety of mechanisms, including via FTP. Support for the GEDI standard is being reviewed, but it is likely that only the more straightforward mechanisms will be supported in the initial release of the system.

Bibliografische zoekacties

Het is mogelijk het systeem te configureren zodat er in externe databases gezocht kan worden op basis van Z39.50. Met deze optie kan personeel in andere databases zoeken om de bibliografische gegevens te verbeteren / aan te vullen alvorens de aanvraag te versturen naar een andere bibliotheek.

1.2 Workflow voor uitgaande aanvragen[//]

Hieronder volgt een overzicht van de verwachte gang door het systeem van uitgaande aanvragen.

De oorspronkelijk aanvraag kan ingediend worden via de optie Nieuwe aanvraag binnen de IBL module, OF kan rechtstreeks ingevoerd zijn door de lener via de WebOpac.

De initiële status van een aanvraag via de WebOpac geeft aan dat deze nog beoordeeld moet worden. Het lenersrecord wordt op de gebruikelijke manier gecontroleerd op blokkades.

Ingevoerde bibliografische gegevens worden als catalogusrecord opgeslagen in een werkbestand, dat op de gebruikelijke manier benaderd kan worden, maar niet direct daaruit opgehaald hoeft te worden voor verdere IBL verwerking.

Nieuwe aanvragen kunnen vergeleken worden met de eigen database(s), voor het geval de lener per ongeluk iets aangevraagd heeft dat wel in de eigen collectie voorkomt. Aanvragen kunne altijd worden omgezet in een reguliere reservering of bestelling (plus reservering) als personeel van mening is dat de titel toch aangeschaft moet worden. Aanvragen kunnen uiteraard ook afgewezen of geannuleerd worden en een bericht hierover aan de lener gestuurd bijv. via e-mail of de WebOpac.

Op basis van de Z39.50 configuratie kan personeel informatie zoeken in externe databases. Deze informatie kan ook opgehaald worden om de titelbeschrijving van de aanvraag de verrijken.

Nadat een leverende bibliotheek is geselecteerd, en eventuele bibliotheken voor doorsturen, berekent het systeem de kosten voor de bibliotheek en de lener. Zulke kosten kunne afhankelijk zijn van de leverende bibliotheek en de lenerscategorie. Als er gebruik gemaakt wordt van “quota” – en de lener heeft de limiet bereikt, kunne de kosten ook nog anders uitvallen.

Ook kan er informatie ingevoerd worden over zaken als ‘gaat het om een boek of kopie', ‘hoe wordt het werk geleverd (per post, elektronsich enz.)'. Het meeste hiervan kan echter automatisch door het systeem worden afgeleid.

Nadat een aanvraag is ingevoerd kan dit onmiddelijk of op gezette tijdstippen aan de leverende bibliotheek gestuurd worden. Wanneer dit gebeurt tussen bibliotheken die het ISOILL protocol gebruiken zal het merendeel van de interactie automatisch door het systeem gedaan worden.

Het systeem houdt een lijst bij van ISOILL berichten die interventie vereisen – bijvoorbeeld een antwoord op een reactie dat er een speciale voorwaarde verbonden is aan de uitleen van het aangevraagde materiaal.

Er is een gedefinieerde set stappen – reacties / antwoorden – binnen het ISOILL protocol die gezet kunnen worden via een “Actie” button (waardoor personeel de juiste antwoorden kan invoeren). Voor handmatig verwerkte aanvragen kunnen sommige van deze stappen overgeslagen worden zonder dat dit de systeemlogica nadelig beïnvloedt.

Bij een fotokopie is de aanvraag afgehandeld zodra de leverende bibliotheek aangeeft dat het exemplaar geleverd is. Voo boeken wordt bij ontvangst een tijdelijke exemplaarbarcode aangemaakt die gebruikt kan worden voor de uitleenprocedure. Bij sommige bibliotheken wordt het boek aan de IBL afdeling geleverd, waarna met een enkele handeling een “reservering” geplaatst kan worden; vervolgens kan het exemplaar doorgestuurd worden naar een filiaal of op de reserveringsplank gezet worden voor de lener. Het systeem is volledig geïntegreerd, zodat de workflow voor reserveringen en IBL identiek kan zijn.

Als de lener om verlenging van het exemplaar verzoekt, wordt dit automatisch in het IBL systeem opgenomen, en (afhankelijk van goedkeuring door het personeel) gaat er dan een bericht met het verzoek naar de leverende bibliotheek.

1.3 Workflow voor inkomende aanvragen[//]

Aanvragen van andere bibliotheken kunen via ISOILL worden ontvangen, in dat geval zijn ze onmiddelijk online zichtbaar, of ze kunen handmatig ingevoerd worden.

De bibliografische gegevens van een inkomende aanvraag worden vergeleken met de catalogus om overeenkomstige records te identificeren. Een aanvraag kan worden ingewilligd of afgewezen. Het is mogelijk eventuele voorwaarden terug te sturen naar de aanvragende bibliotheek via het ISOILL protocol.

Als de aanvraag gekoppeld is aan een record in de catalogus kan deze verder behandeld worden als een reguliere reservering of magazijnaanvraag met als afhaallocatie de IBL afdeling.

Wanneer het exemplaar eenmaal beschikbaar is op de afdeling die verantwoordelijk is voor de verzending kan het uitgeleend worden aan de aanvragende bibliotheek, een bericht gestuurd worden en een verzendetiket geprint worden in een enkele handeling.

Er kan een ‘lenersrecord' gemaakt worden voor de aanvragende bibliotheek waardoor alle uitleeninformatie op de gebruikelijke manier beschikbaar is.

Er is enig verschil in opties met betrekking tot de initiële aanvragen. Voor inkomende ISOILL aanvragen is het bijvoorbeeld niet toegestaan inkomende bibliografische gegevens te wijzigen (want DAT is wat er aangevaargd is), aan de andere kant moet dit juist kunen voor handmatig ingevoerde aanvragen.

Aanvragen die niet geleverd kunen worden, kunnen automatisch doorgestuurd worden naar andere bibliotheken.

1.4 Aanvragen tonen[//]

Een reguliere set zoekingangen en displays is beschikbaar. Het is bijvoorbeeld mogelijk te beperken op aanvragen van een bepaalde bibliotheek of voor een bepaalde vestiging, aanvragen met een specieke status enz.

Leners kunnen de voortgang van hun aanvragen volgen via de WebOpac onder Gebruikersactiviteiten.

2 Parameters[//]

De parameters voor de IBL module worden ingesteld in AFO 822. Zie de help van die AFO voor meer informatie.

De IBL module maakt ook gebruik van mailmerge technologie, zie de algemene help voor mailmerge voor meer informatie over dit onderwerp.

Hieronder volgt een kort overzicht van een aantal concepten.

2.1 IBL afdelingen[//]

De parameters voor IBL afdelingen in AFO 822 bepalen de details van “uw” organisatie. Dit is de organisatie waar aanvragen worden ontvangen en verstuurd. Een enkele IBL afdeling komt overeen met een complete meta-instelling uitleen, maar binnen één meta-instelling kunnen er meerdere afdelingen zijn. Er kan bijvoorbeeld een enkele IBL afdeling zijn die uitgaande aanvragen van leners geregistreerd bij die meta-instellingen verwerkt, maar meerdere IBL afdelingen kunnen de aanvragen “beheren” voor een set van leners / exemplaren. Voor de buitenwereld kan het systeem bestaan uit meerdere “bibliotheken” waar een aanvraag ingediend kan worden, maar als de aanvragen eenmaal ontvangen zijn is verdere verwerking ondeelbaar.

2.2 IBL bibliotheken[//]

IBL bibliotheken zijn bibliotheken waarheen u aanvragen verstuurt en van wie u aanvragen ontvangt. Met deze parameters in AFO 822 definieert u dus de gegevens van andere organisaties.

Let op

Voor BL en PICA zijn er speciale formaten voor elektronische levering met speciaal geformatteerde e-mails. Het is noodzakelijk om de mailserver, wachtwoorden e.d. te definiëren om e-mails te kunnen verzenden.

2.3 Consortia / Meerdere instellingen[//]

Leverende bibliotheken wordne gedefinieerd op systeembrede basis. Dit is om technische redenen noodzakelijk voor communicatie tussen ISOILL protocol en systeem (op het moment van ontvangst en verzending van zulke berichten is “meta-instelling” geen beschikbare optie). Op zich is het natuurlijk prettig dat dergelijke definities slechts eenmalig ingevoerd hoeven te worden.

Maar als er wel meerdere organisaties zijn die IBL gebruiken, dan zijn vele van de parameters ‘specifiek' voor hen. De parameters voor bibliotheken (op een enkel invulscherm) zijn derhalve een combinatie van systeembrede en afdelingsspecifieke.

De ISOILL technische velden zijn systeembreed.

· Bibliotheekcode (zoals RLG:TCDU)

· Bibliotheeknaam

· Leveringstype

· ISOILL e-mail / IP adres

· Blokkeer / tot

· Web adres

Alle overige velden moeten wroden gedefinieerd per IBL afdeling.

Daarbij dient ook het volgende in acht te worden genomen.

· Z39.50 zoeken is systeembreed gedefinieerd (en gerelateerd aan parameters in AFO 651). Aangezien het symbool voor de bibliotheek wordt gedefinieerd voor de database, dienen IBL afdelingen er voor te zorgen dat ze altijd met hetzelfde symbool aan de biblitheek refereren.

· Er wordt slechts één ISOILL database gedefinieerd, die dus gedeeld wordt door meerdere organisaties. Daarom kunnen algemene bibliografische zoekacties voor aanvragen records opleveren van andere organisaties. Gebruikers hebben dan GEEN rechten om deze aanvragen te wijzigen, maar enige "read-only" toegang is onvermijdelijk.

· Uittechnisch oogpunt zijn alle bibliotheekcodes beschikbaar voor gebruik op alle punten waar een leverancier gekozen kan worden, MAAR verdere verwerking van een aanvraag met zo'n leverancier wordt opgeschort totdat de noodzakelijke IBL afdeling specifieke parameters zijn ingesteld.

3 Kostenschema's[//]

In deze sectie wordt de kostenberekening binnen de IBL module toegelicht. Aangezien bibliotheken op vele verschillende manieren kosten in rekening kunnen brengen, is deze materie vrij complex. Er kunnen meerdere manieren zijn om een zelfde resultaat te bereiken. In de praktijk zal een bibliotheek slechts een deel van de mogelijkheden benutten, waardoor het uiteindelijk simpeler zal zijn dan de totaaloplossing doet vermoeden.

Er zijn drie verschillende soorten kosten die in overweging genomen moeten worden – hoeveel brengt de bibliotheek in rekening voor het leveren van materiaal, hoeveel moeten leners betalen voor het elders aanvragen van materiaal en wat brengen andere bibliotheken in rekening voor het leveren van materiaal.

3.1 Overzicht[//]

Kostenschema's zijn een manier om de regels vast te stellen die bepalen hoe de kosten berekend moeten worden. De velden die hiervoor gebruikt kunnen worden zijn:

· Of het een inkomende of uitgaande aanvraag betreft

· Het service type (Uitlening of Kopie)

· Het type exemplaar

· Het aantal pagina's van een kopie

· Of de kosten doorbelast moeten worden op een budget

· Of de kosten voor een lener ook copyright kosten betreffen

· Het service niveau (normaal, spoed e.d.).

· De lenerscategorie

· Of de lener zijn/haar quota heeft overschreden

Er kunnen zoveel verschillende kosten schema's als nodig gedefinieerd worden.

Zodra een schema is gedefinieerd, kan het gekoppeld worden aan een Bibliotheek – dit bepaalt vervolgens hoe kosten worden berekend voor:

· Exemplaren uitlenen aan die bibliotheek

· Exemplaren lenen van die bibliotheek

· Doorbelasten op een budget of

· In rekening brengen bij een individuele lener

Dus als in de praktijk de meerderheid van bibliotheken dezelfde regels hanteren, kan worden volstaan met een enkel kostenschema dat wordt gekoppeld aan al deze bibliotheken. Als er wijzigingen zijn kunnen die ook in één keer worden doorgevoerd voor alle gekoppelde bibliotheken.

3.2 Voorbeeld[//]

Hieronder een voorbeeld van hoe een gedetailleerd kostenschema er uit zou kunnen zien:

Ten eerste wordt dit scherm opgesplitst in de vier onderdelen:

· Levering de kosten voor het uitlenen aan een andere bibliotheek

· Aanvraag de kosten voor het lenen van een exemplaar

· Budget de kosten door te belasten op een budget

· Lener de kosten voor een individuele lener

Als we naar de kosten voor leveren kijken is dat 5,00 voor uitlening. Voor een dissertatie is dat 7,00. Voor een fotokopie is het ook 7,00 PLUS 1,00 extra per pagina. Als er meer dan 10 pagina's zijn, is het additionele bedrag nog maar 0,80 par pagina.

De kosten “per pagina” zijn altijd een additioneel bedrag wanneer er een pagina bereik is ingevoerd.

Voor lenen bedragen de kosten 15,00, behalve als er copyright kosten bijkomen, dan is het 25,00. Kopieën kosten dan 10,00 plus 2,00 per pagina.

In dit voorbeeld is de bibliotheek genereus: kosten voor een budget of individuele lener zijn lager. Voor een lener (regels 16,18) zijn de kosten slechts 3,50 + 0,50 per pagina, met uitzondering van EXTERNE leners die 23,00 moeten betalen (plus 0,50 per pagina).

Voor de externe lener is de display “13.00 / 2.00 EUR” – zie de opmerking m.b.t. tot administratiekosten hieronder.

3.3 Hoe worden de kosten bepaald[//]

Bij het bepalen van de kosten kijkt het systeem naar elke regel die is gedefinieerd voor de “rol” (d.w.z. welk type kosten berekenen we) om te bepalen welke regel het best van toepassing is. Meerdere regels zouden kunnen gelden – bij een kopie voor een EXTERNE lener ziet het systeem regel 16 (3,50) maar vervolgens ook regel 18, dus wordt het uiteindelijk 23,00.

Er kunnen regels van toepassing zijn in een combinatie van algemene en specifieke omstandigheden. Kijkend naar regels 14 en 15 zien we dat externe leners 13,00 moeten betalen, maar dat een dissertatie maar 9,00 kost. Wat moet een externe lener dan voor een dissertatie betalen? Het mechanisme is om de laatste van toepassing zijnde regel te gebruiken, dus in dat geval 9,00 (15 komt na 14).

Regels kunnen omhoog en omlaag verplaatst worden. In het vorige geval zou 13,00 misschien beter zijn en moet de ‘dissertatie' regel boven de ‘externe leners' regel geplaatst worden (dan wordt de ‘externe leners' regel later gevonden en dus toegepast).

Admin kosten

Bij het belasten van een budget of een lener, ontstaat de vraag WANNEER De kosten precies betaalbaar zijn. Moeten ze in rekening worden gebracht (en betaalbaar zijn) als de aanvraag wordt geplaatst. Maar misschien kan de bibliotheek niets vinden bij de gebruikelijke leveranciers en moet er intensiever gezocht worden. Sommige bibliotheken hebben als beleid dat leners altijd moeten betalen, of er nu een exemplaar geleverd wordt of niet.
De administratiekosten kunnen als vast bedrag toegevoegd worden aan het schema, onmiddellijk te betalen bij plaatsen van de aanvraag. Het zijn dus kosten voor het administreren en niet voor de aanvraag zelf. Het staat bibliotheken vrij hier al of niet gebruik van te maken.
De kosten zijn betaalbaar op het moment van invoer in het systeem – door de lener via de WebOpac of door personeel. Op dit moment is er wellicht nog geen leverancier gekozen, dus wordt een default kostenschema toegepast – dus in theorie zijn deze kosten NIET gekoppeld aan een bepaalde leverancier. (het is dus een zeer algemeen onderdeel van een kostenschema).
Maar om alles toch op één plek te houden vormen de administratiekosten toch onderdeel van de totale regelset, d.w.z. binnen het kostenschema.
Voor met name openbare bibliotheken geldt vaak dat er een vast bedrag is, onafhankelijk van nadere factoren.
Als er administratiekosten zijn gedefinieerd voor een regel, dan verschijnt dit als / 2.00 gevolgd door het bedrag van de kosten.
De administratiekosten zijn ALLEEN van toepassing op kosten voor leners of budgetten, met andere woorden alleen voor uitgaande aanvragen.

Overige kosten

Met deze optie kunnen twee extra velden bij het schema worden gedefinieerd. Dat zijn:

· Kosten voor te laat inleveren/vermissing: Kosten berekend aan de bibliotheek bij te late inlevering of zoekraken.

· Restitutie: Restitutie van bovenstaande kosten indien vermist exemplaar geretourneerd wordt.

Hiermee kunnen kosten opgeslagen worden die aan de bibliotheek berekend worden.

Kosten per service niveau

Met de optie Service niveaus kunnen ADDITIONELE kosten bij het schema worden gedefinieerd, naast de hierboven genoemde kosten.

Voor elk van deze niveaus kunnen additionele kosten gedefinieerd worden door het selecteren van een regel.

Er verschijnt dan een invoerscherm met vergelijkbare workflow als voor de reguliere kosten. In de praktijk zullen hier doorgaans eenvoudige definities gemaakt worden bijvoorbeeld alleen voor uitlening en kopie.

Hoewel uitgegaan wordt van simpele definities, maar als de bibliotheek gewone leners 2,00 extra willen berekenen voor spoedaanvragen en externe leners 3,50 dan kan dat.

4 Budgetten[//]

Kosten voor uitgaande IBL aanvragen kunnen doorbelast worden op afdelingsbudgetten, in plaats van dat er door individuele leners betaald moet worden.

Of een aanvraag betaald wordt door een lener of uit een budget kan per aanvraag ingesteld worden, maar kan ook aangeboden worden als optie in de WebOpac wanneer leners zelf aanvragen plaatsen.

Hieronder wordt beschreven hoe budgetten beheerd en gebruikt worden binnen het systeem. Wanneer er “afdeling” staat wordt er een afdeling binnen de organisatie (universiteit of bedrijf) bedoeld. Als het over de IBL afdeling gaat, wordt dat expliciet zo genoemd.

Budgetcodes worden beheerd via de optie IBL Budgetten in AFO 822.

Budgetten worden gedefinieerd voor de meta-instelling uitlening en kunnen derhalve worden gedeeld door meerdere IBL afdelingen.

Afedelingen setup

Met de optie Afdelingen setup kunnen individuele budgetten gekoppeld worden aan een afdeling, als gedefinieerd in AFO 482– Lener Authority Lijsten – Identiteit Afdeling.

Dit is optioneel en wordt gebruikt wanneer facturering voor aanvragen per afdeling gedaan moet worden in plaats van per individueel budget.

Lenerscategorieën setup

Het is mogelijk de WebOpac te configureren zodat leners een budget kunnen kiezen waaruit betaald moet worden. Wanneer deze optie inderdaad in gebruik is, dan kan deze bijvoorbeeld maar voor bepaalde lenerscategorieën gelden.

Budget veld in lenersrecord

AFO 482 heeft twee velden onder de Algemene Lener Instellingen: IBL Budget status en IBL Budgetten, die geselecteerd kunen worden voor in te voeren en te verbeteren gegevens.

Het eerst veld bepaalt of en hoe keuze van budget aangeboden wordt in de WebOpac. In het tweede veld kunenn één of meer budget codes gekoppeld worden.

5 Facturen[//]

Bij het verwerken van facturen voor IBL aanvragen dienen er weer diverse aspecten in acht genomen te worden:

Registreren van facturen van leverende bibliotheken voor ontvangen materiaal
Aanmaken van facturen voor aanvragende bibliotheken voor geleverd materiaal
Facturen voor individuen voor uitgaande aanvragen
Facturen voor afdelingen/budgetten voor uitgaande aanvragen

Facturen voor individuele leners

Kosten die voortvloeien uit aanvragen staan op de gebruikelijke manier in het lenersrecord en kunnen via AFO 414 betaald worden. Momenteel kunnen expliciete facturen voor reserveringskosten, aanvragen e.d. NIET beheerd worden via de uitleenmodule.

Registreren van facturen van leverende bibliotheken

Facturen van leverende bibliotheken kunnen NIET ingevoerd worden in het systeem (zoals dat bijvoorbeeld wel kan voor facturen van leveranciers in de Bestelmodule).

Maar indien gewenst kunnen facturen wel geregistreerd worden bij de kosten voor een individuele aanvraag. Dit kan dan bijvoorbeeld in SSP gebruikt worden om aanvragen behorend bij een bepaalde fcatuur/leverancier te vinden. Het is NIET mogelijk in een online index te zoeken op dergelijke factuurnummers.

Facturen voor afdelingen/budgetten

Er kunne facturen gegenereerd worden voor nog niet gefactureerde aanvragen met de “Factuurverwerking” optie onder IBL budgetten.

Alle aanvragen die ingevoerd zijn tot aan (maar zonder) “vandaag” om er voor te zorgen dat de ‘afbakening' van facturen duidelijk is – dat wil zeggen dat op een bepaalde dag aanvragen niet op meerdere facturen verschijnen (voor één budget).

Vervolgens worden aparte facturen gegenereerd voor elk budget, met het totaalbedrag voor alle aanvragen op die budget code. Of ze worden samengevoegd op basis van wat er onder de groepering per afdeling is vastgelegd.

Het formaat van de factuurnummers wordt bepaald per IBL afdeling (tabblad Algemeen).

5.1 Genereren van facturen[//]

De facturen genereren job is een standaard “taak” binnen Vubis – die online in batch of in memory uitgevoerd kan worden

De verwerking is vrij simpel.

Voor elke IBL afdeling binen het systeem selecteert het proces alle aanvragen die uit een budget betaald moeten worden, die betaalbaar zijn en die nog niet eerder gefactureerd zijn.

Het formaat van de factuurnummers wordt bepaald per IBL afdeling

Bijvoorbeeld

REK.2007/99999999

Dit resulteert in facturrnummers “REK.2007/0000001”, “REK.2007/0000002” enzovoorts. Het systeem kent volgnummers toe, zodat het 999999 gedeelte altijd uniek is.

5.2 Facturen printen[//]

Om de factuur te printen wordt gebruik gemaakt van mailmerge. (Zie ook de algemene help over mailmerging voor meer informatie).

Het hoofddocument (d.w.z. het document dat de lay-out van de factuur bepaalt) kan gedefinieerd worden voor Budget code of voor Afdeling via Afdelings setup. (NB Afdeling is in dit geval de afdeling binen de organisatie, niet de IBL afdeling).

Als aanvargen geggropeerd zijn, wordt de lay-out van de afdeling gebruikt en anders die van het budget.

Zoals eerder beschreven is het mogelijk budgetten al dan niet te groeperen – en dus zijn facturen ook een mengeling van budget specifieke en groepsfacturen.

Hieronder een voorbeeld van een hoofddocument voor facturen

5.3 Facturen voor aanvragende bibliotheken[//]

Hieronder wordt toegelicht hoe aanvragende bibliotheken gefactureerd kunen worden.

Aangezien dit proces hoort bij externe bibliotheken, wordt het geïnitieerd vanuit de optie IBL Bibliotheken in AFO 822.

De workflow is vrijwel identiek aan die voor budgetten.

5.4 Genereren van facturen voor inkomende aanvragen[//]

De manier waarop facturen gemaakt worden is echter wezenlijk anders. De “Betaalmethode” toegekend aan elke aanvraag bepaalt hoe facturen worden geselecteerd en gegenereerd.

Er is een default betaalmethode voor elke bibliotheek. Deze wordt toegekend aan elke aanvraag – maar kan per aanvraag aangepast worden.

De betaalmethode dient om aan te geven HOE betaling tussen bibliotheken afgehandeld wordt. Standaard opties hierbij zijn o.a. “Voucher”, “Prepaid”, “IFM”, “Invoice”. De IBL afdeling kan daar nog eigen opties aan toevoegen.

Het proces wordt uitgevoerd op basis van “Betaalmethode”. Een factuur bevat derhalve alle nog niet gefactureerde aanvragen voor de opgegeven betaalmethode. Doorgaans gebeurt dit per bibliotheek, maar hieronder wordt uitgelegd dat het ook anders kan.

Factuur is in deze context dus een verzameling IBL aanvragen – het systeem maakt deze selecties voor alle aanvragen. In sommige gevallen worden leveringen ‘weggestreept' tegen aanvragen, bijvoorbeeld binnen een consortium. In zo'n geval houdt een overkoepelende organisatie de totalen bij, waarna er een ‘schuld' kan overblijven.

Het systeem genereert dan nog wel facturen, maar deze kunnen worden beschouwd als een overzicht van geleverde aanvragen in plaats van een te betalen factuur. Of het resultaat er ook uitziet als een factuur hangt af van de lay-out die voor deze output gekozen wordt.

De betaalmethode bepaalt dus twee dingen:

Ten eerste wat de lay-out is van een pseudo factuur voor elke betaalmethode. De fysieke output wordt geregeld via mailmerge. Voor een betaalmethode die in een echte factuur resulteert kan een andere lay-out gehanteerd worden met bedragen, totalen e.d.

Als de facuur eigenlijk alleen maar een overzichtslijst is, kan waarschijnlijk volstaan worden met enige details van elke aanvraag.

Ten tweede dat we NIET selecteren voor individuele bibliotheken (in het geval van een consortium). Als er een speciale betaalmethode is voor het consortium kunnen we vervolgens het factuurproces uitvoeren voor alle aanvragen met die betaalmethode. De fysieke output wordt NIET opgesplitst naar afzonderlijke bibliotheken.
De lay-out van de pseudo factoor wordt dus afgeleid van de betaalmethode en niet van de bibliotheek. Dit impliceert dat het factuuradres onderdeel moet zijn van het hoofddocument.

Bij het starten van het factuurproces wordt gevraagd voor welke betaalmethoden dit uitgevoerd moet worden. Er kunnen dus aparte runs gedaan worden (of ingesteld worden op atomatische maandelijkse verwerking) voor elke betaalmethode. Met andere woorden: regulier facturen automatisch op de 1^e van de maand en overzichtslijsten voor consortium handmatig op elk gewenst moment.

Dit houdt ook in dat bepaalde betaalmethoden uitgesloten kunnen worden van het genereren van facturen. Als er geen proces is dat ze selecteert, worden er geen facturen gegenereerd.

5.5 Overizcht hoofddocumenten facturen[//]

Er zijn twee sets facturen – de interne d.w.z. die aan “onze” leners voor uitgaande aanvragen en de facturen voor externe bibliotheken (inkomende aanvragen). Deze kunnen als volgt uitgesplitst worden.

Uitgaande aanvragen

· Voor individuele leners Niet via IBL proces, maar via AFO 431

· Voor afdelingen Deze worden per afdeling gedefinieerd

· Voor budgetten Deze worden voor elk budget gedefinieerd

Inkomende aanvragen

· Gegroepeerd per betaal methode

· Individueel voor elke binliotheek per betaal methode en per factuuradres

De lay-out voor de afdelingen wordt gedefinieerd via AFO 822 – IBL Budgetten – Afdelingen setup.

Voor individuele budgetten wordt voor elk budget een lay-out gedefinieerd.

Voor facturen voor uitgaande aanvragen wordt de lay-out gedefinieerd op basis van betaal methode uit AFO 822 – Algemene opties – Betaal methoden.

De lay-out wordt altijd gedefinieerd voor elke betaal methode in is nooit afhankelijk van aanvragende bibliotheek (afgezien van consortia).

Hoewel de definities als hierboven beschreven zijn, is er geen reden waarom deze niet dezelfde padnaam zouden kunnen hebben voor het hoofddocument.

5.6 Voorbeelden[//]

Hieronder twee voorbeelden van aangepaste output voor een bibliotheek. Deze voorbeelden zijn bedoeld om voornoemd concept van “pseudo facturen” te illustreren.

Er zijn twee mogelijke manieren om kosten te verhalen voor Britse bibliotheken. De aanvraag kan rechtstreeks van een bibliotheek afkomstig zijn (maar dit is ongewoon) of via de British Library.

Als de aanvraag via de BL is gekomen, nemen we aan dat betaal methode in de aanvraag “BL” was. Voor rechtstreeks ontvangen aanvragen is de methode “FACTUUR”. (dit is bibliotheek specifiek!).

Dan zouden de parameters kunne zijn:

Betaal type	Output formaat	Bibliotheken samenvoegen
BL	BriefListingTemplate.doc	Ja
FACTUUR	InvoiceFormatTemplate.doc	Nee

We hebben deze aanvragen van bibliotheekcode “16-12345” en van “16-9876”

Aanvraag	Bibliotheek	Betaal type	Bedrag
R1234	16-12345	BL	6.50
R4567	16-12345	BL	6.50
R9876	16-12345	FACTUUR	4.00
G934349	16-9876	BL	6.50

Dan zou de output er ongeveer zo uitzien

d.w.z. alle aanvragen met betaal methode BL staan op deze “pseudo factuur”. In feite is dit slechts een overzichtslijst.

Deze lay-out komt overeen met “BriefListingTemplate.doc” (afgeleid van Betaal type)

Voor de FACTUUR krijgen we dan:

Deze lay-out komt overeen met “InvoiceFormatTemplate.doc” gedefinieerd voor betaal methode FACTUUR.

6 Berichtenproductie[//]

Er zijn vele berichten beschikbaar voor verzending aan leveranciers, aanvragers en lokale klanten (leners). Zulke berichten worden automatisch en elektronisch verzonden aan ISOILL bibliotheken op basis van het ISOILL protocol, aar voor andere bibliotheken moeten ze apart gegenereerd worden als tekstberichten.

Naast berichten kunnen er ook verzendetiketten, geleidebonnen e.d. gegenereerd worden.

Er zijn in feite drie sets berichten

· Berichten aan andere bibliotheken

· Berichten aan klanten

· Output voor verwerking, d,w,z, voor de IBL afdeling

Onder berichten aan andere bibliotheken vallen de aanvraag zelf, algemene berichten, annuleringsverzoeken, rappels, terugvorderingen e.d. – er zijn 27 verschillende types beschikbaar.

Onder interne output vallen o.a. verzendetiketten, geleidebonnen.

Onder berichten aan leners vallen beschikbaarheidberichten, annuleringsberichten, status rapporten.

De te gebruiken lay-out kan desgewenst voor elke bibliotheek afzonderlijk gedefinieerd worden. Voor Noord-Amerikaanse bibliotheken kan bijvoorbeeld het ALA model gebruikt worden, terwijl voor internationale aanvragen het IFLA model beter is.

Lay-outs kunnen ook worden gedefinieerd in de contacttaal van de bibliotheek, bijvoorbeeld om in Welsh een aanvraag te plaatsen bij een bibliotheek in Wales.

Om te voorkomen dat de individuele lay-out voor de (27) berichten voor elke bibliotheek of voor elke IBL afdeling apart gedefinieerd moet worden, kunnen berichten gegroepeerd worden in “Berichtensets”. Er kunnen dan bijvoorbeeld een paar verschillende sets gedefinieerd worden, die afhankelijk van het type bibliotheek gekoppeld kunnen worden.

Er zijn 3 categorieën Berichtensets te onderscheiden:

· Sets voor bibliotheken

· Sets IBL afdelingen

· Sets voor leners

Dan is er ook nog een vierde categorie – voor annuleringsberichten – zo dat de tekst van het bericht aangepast kan worden aan de reden voor annulering van een aanvraag.

6.1 Berichten aan klanten[//]

Normaliter kan een klant de status van een aanvraag zien via de WebOpac. Derhalve is het versturen van een ‘gedrukt' bericht m.b.t. de levenscyclus van een uitgaande aanvraag een kwestie van beleid van de IBL afdeling. Zo is het aannemelijk dat er een bericht verstuurd wordt wanneer de aanvraag daadwerkelijk beschikbaar is, maar bijvoorbeeld niet wanneer de leverende bibliotheek het pakje opgestuurd heeft.

De te versturen berichten en de manier van versturen worden voor elke aanvraag bepaald, afhankelijk van een “contact methode” parameter, hoewel de keuze voor het versturen van een bepaald bericht soms een onderdeel is van het soort bericht. Bijvoorbeeld annuleringsverzoek voor uitgaande aanvraag – als de lener hierom verzocht heeft, heeft het geen zin de lener een annuleringsbericht te sturen.

Er kunnen ook ad-hoc berichten aan klanten gestuurd worden, als e-mail of in gedrukte vorm.

Het versturen van een bericht aan een klant kan op de volgende manieren geïnitieerd worden:

· Bij annulering van een aanvraag kan een “reden” toegevoegd worden. Aan elke reden kan een bericht gekoppeld zijn. Als de annulering wordt ingevoerd heeft personeel de mogelijkheid de klant een bericht te sturen.

· Als een aanvraag is gemarkeerd als “niet mogelijk te leveren”, kan ook een bericht gekoppeld zijn en heeft personeel de mogelijkheid de klant een bericht te sturen.

· Op elk moment kan een ad-hoc bericht gekozen worden uit geldige berichttypes.

· Als een aanvraag is gemarkeerd als “geleverd”, heeft personeel de mogelijkheid de klant een bericht te sturen

Bij ontvangst van een exemplaar is het mogelijk het systeem automatisch een ‘beschikbaarheidsbericht' te laten sturen aan de klant.

Zulke berichten kunnen op elk moment verstuurd worden. Het systeem houdt de geschiedenis van verstuurde berichten bij. Een eerder verstuurd bericht mag in alle gevallen opnieuw geprint worden, het systeem toont dan een waarschuwing dat het bericht al eerder geprint is.

6.2 Fysieke productie van berichten[//]

Berichten kunnen onmiddellijk geprint worden of geselecteerd worden voor latere verwerking in een apart proces. Printen kan altijd naar een printer die beschikbaar is op de PC waarop gewerkt wordt en kan een lokale of netwerk printer zijn (zoals gebruikelijk binnen Vubis).

Er wordt gesproken over “berichtencode”, maar in feite gaat het om mailmerge sjablonen. De verwerking wordt elders beschreven (zie ook de algemene help voor mailmerge), maar hieronder volgt in het kort het proces

Wanneer berichten vereist zijn maakt het systeem een bestand aan met ALLE mogelijke velden en verstuurt dit bestand met de naam van het sjabloon naar de applicatie. Dit resulteert in een automatische mailmerge om de gegevens samen te voegen met het hoofddocument en een uitvoerbestand aan te maken. Dit uitvoerbestand kan automatisch geprint worden, het kan automatisch per e-mail verstuurd worden of het “op het scherm blijven” voor verdere handmatige aanpassing (en vervolgens verzending of opslag).

Een sjabloon kan er uitzien als:

De tekst tussen {} wordt automatisch vervangen door de data uit de aanvraag. Het gaat hier dus om een mailmerge hoofddocument en alle mogelijkheden van tekstverwerking zijn beschikbaar om berichten de juiste opmaak te geven naar wens van de bibliotheek.

Er wordt een set voorbeeld sjablonen meegeleverd (zoals eentje voor elke standaard annuleringsreden, eentje voor elke “niet geleverd” reden).

Berichten voor aanvragende of leverende bibliotheken

Berichten aan aanvragende bibliotheken worden in de meeste gevallen automatisch verzonden aan ISOILL bibliotheken.

Voor niet-ISOILL bibliotheken zijn de volgende berichten beschikbaar. Voor elk type bericht kan de gewenste lay-out (Word sjabloon) gedefinieerd worden per leverancier. Als er niets is gedefinieerd voor een type bericht, dan wordt er geen bericht gegenereerd.

Bepaalde berichten types worden alleen gegenereerd als de bijbehorende “actie” handmatig gedefinieerd wordt voor een aanvraag (zie de help van AFO 821 voor Acties en Gebeurtenissen). Het is bijvoorbeeld in principe mogelijk de aanvragen bibliotheek een bericht te sturen dat u het exemplaar zult leveren, maar dit gebeurt alleen als personeel de moeite neemt een dergelijke Actie te initiëren.

Sommige van deze berichten komen overeen met de ISOILL berichten hiervoor. In de praktijk is het onwaarschijnlijk dat een complete set gebruikt zal worden voor handmatige aanvragen. Het is aannemelijk dat de daadwerkelijke verzendmethode per e-mail zal zijn en niet in gedrukte vorm. Niettemin kan de bibliotheek dit allemaal gebruiken.

Daarnaast is het voor ISOILL bibliotheken mogelijk om “boodschappen” te versturen in gedrukte vorm of per e-mail. Normaliter worden deze via het protocol verstuurd, maar dit is een extra mogelijkheid (bijvoorbeeld wanneer er een probleem is met het ISOILL proces).

Het feitelijke output mechanisme voor berichten aan klanten is via mailmerge. Afhankelijk van de context kunnen berichten afzonderlijk of als batch proces gegenereerd worden.

Daarnaast kunnen er verzendetiketten gegenereerd worden voor verzending (aan aanvragende bibliotheken) en retournering (aan leverende bibliotheek).

6.3 Berichten printen[//]

De berichten die wel geselecteerd maar nog niet geprint (of per e-mail verzonden) zijn, kunnen via een aparte menu optie alsnog uitgevoerd worden.

(Dit is vergelijkbaar met AFO452 in de zin dat de berichten gegroepeerd zijn per type bericht).

Aangezien deze op ad-hoc basis worden gegenereerd (d.w.z. specifiek voor elke aanvraag) op elk willekeurig moment, bevat de lijst alle uitstaande berichten. Als ze niet geprint worden, groeit de lijst alleen maar.

Op elk willekeurig moment kan een bepaald type output gegenereerd worden voor een aanvraag. Maar zodra een stel berichten geprint is (d.w.z. daadwerkelijke gedrukte of e-mail output) dan worden deze samen gegroepeerd en bewaard gedurende een opgegeven periode zodat ze in bulk opnieuw afgedrukt kunnen worden (als er bijvoorbeeld iets misgegaan is met de printer).

Zulke stellen berichten kunnen worden geselecteerd om (opnieuw) te printen. Selectiecriteria zijn datum/tijd bereik (gebaseerd op de tijd waarop de actie die resulteerde in het bericht werd uitgevoerd), de gewenste lay-out (Word sjabloon code), de reagerende bibliotheek. Output kan ook gedaan worden o.b.v. een simpel criterium, zoals "output records 1-50" (hoewel dit niet eenvoudig is – bij de selectie weet het systeem niet om hoeveel pagina's output het zal gaan, want dat is afhankelijk van de tekstverwerker).

6.4 Berichtensets[//]

Afhankelijk van het soort bericht zijn er sets voor de afdeling en de externe bibliotheken. Er wordt eerst gevraagd welk type berichten u wilt definiëren:

· Afdelingen

· Bibliotheken

· Leners

· Annuleringen

Als u een optie kiest verschijnt een overzicht van de bijbehorende berichtensets.

Selectie van een set voert naar een overzicht van de verscillende beschikbare berichten.

Enige algemen opmerkingen

Als er geen hoofddocument is gedefinieerd impliceert dit, dat deze output niet nodig is.

Voor afdelingen kunnen allerlei eitiketten e.d. geprint worden bij levering, ontvangst, retournering. Deze zijn er in diverse “smaken”- wanneer er meer dan één “Label type A” , “Label type B” enzovoorts is gedefinieerd dan krijgt men de keuze, zodat een etiket dat het beste past bij de afmetingen van het pakje geselecteerd kan worden. Een ander voorbeeld is het retourneren van exempalren in binnen- of buitenland.

6.5 Achtergehouden prints [//]

Elke output die niet onmiddellijk verwerkt wordt, komt terecht in een “achtergehouden prints” wachtrij. Dit geldt ook voor output gegenereerd via een nachtwaker proces, dit gebeurt automatisch maar komt dan in een wachtrij voor fysieke output.

Deze zijn te vinden via de optie “Achtergehouden prints” in AFO 821.

7 Functionele verwerking[//]

Verwerking van IBL aanvragen geschiedt via AFO 821. Op het menu staan de drie voornaamste opties.

· Meldingen

· Inkomende aanvragen

· Uitgaande aanvragen

Over het algemeen worden Inkomende an Uitgaande aanvargen afzonderlijk beheerd. In de sectie “Meldingen” geven gebeurtenissen aan dat actie vereist is (voor inkomende of uitgaande aanvragen).

7.1 Inkomende aanvragen[//]

Met deze optie verschijnt een overzichtsscherm met een u een samenvatting van de inkomende aanvragen per status.

Wanneer u een regel selecteert, ziet u een overzicht van alle aanvragen met de geselecteerde status. Hier vandaan kunnen de details van een individuele aanvraag bekeken worden.

7.2 Uitgaande aanvragen[//]

Een zelfde soort overzicht wordt getoond. De mogelijke statussen zijn iets anders, maar de verdere verwerkingsopties zijn gelijk.

Net als bij inkomend aanvragen kunnen ook hier handmatig nieuwe aanvragen toegevoegd worden. Maar het is aanemelijk dat leners de WebOpac zullen gebruiken om aanvragen te plaatsen in plaats van dit via personeel te laten doen.

7.3 Aanvragen zoeken[//]

Met deze optie kunt u specifieke zoekacties in de aanvragen database uitvoeren. Hiervoor zijn diverse zoekmogelijkheden beschikbaar.

Deze zoekacties kunnen gestart worden vanaf de hoofdschermen voor aanvragen (als hierboven beschreven).

Bibliografisch zoeken

U kunt specifieke zoekacties in de aanvragen database uitvoeren. Als u deze optie kiest verschijnt het standaard scherm voor bibliografische zoekacties.

Opmerkingen

De bibliografische informatie voor uitgaande aanvragen wordt opgeslagen in een parate database, aangemaakt bij installatie van de module, samen met eigen indexen. Het is echter mogelijk om een uitgaande aanvraag te koppelen aan een record in de hoofd database(s) van het systeem – in het geval de lener niet heeft opgemerkt dat de bibliotheek de aangevraagde titel wel in bezit heeft.

Inkomende aanvragen worden opgeslagen in een speciale aanvragen database. Zodra er een match gemaakt is met een bestaand record in de lokale database, worden ze ook geïndexeerd op records in de hoofd database.

Het systeem zal de zoekactie echter beperken tot die titels waarvoor een IBL aanvraag bestaat.

Nadat een record gevonden is, moet men de “Kies record” optie kiezen vanaf het volledige record scherm, dit voert naar een scherm met een overzicht van uitstaande aanvragen voor de geselecteerde titel.

Aanvragen zoeken

Het is ook mogelijk aanvragen te zoeken op:

· Zoekterm: de term waarop gezocht moet worden.

· Search type offers a dropdown list of the three types

De overige velden maken verdere beperking van de zoekactie mogelijk.

· Status Dit is een dropdown lijst van mogelijke statussen. De STATUS selectie geldt voor de GEHELE aanvraag.

· Inkomende / Uitgaande aanvragen

En dan nog twee mogelijkheden om de zoekactie te beperken.

· Datums: Deze set van 4 velden maakt het mogelijk een datum range te specificeren – gebaseerd op een specifiek datum type uit de aanvraag.

· Beperk zoekactie tot actuele transacties: Zoeken kan nogal complex zijn, omdat er meerdere transacties kunnen zijn voor een enkele aanvraag (bijv. aangevraagd door A, doorgestuurd naar B enz.). Met deze optie wordt aangegeven of alleen naar de meest recente transactie gezocht moet worden, of dat de hele “geschiedenis” meegnomen moet worden. Als de optie niet is aangevinkt en er wordt gezocht op “leverdatum” kan een aanvraag gevonden worden die “geleverd” is, maar die ook op enig moment een status “niet geleverd” had.

8 Aanvragen Display[//]

Nadat er gezocht is, een aanvraag geselecteerd is e.d. verschijnt het invoerscherm met de gegevens van de aanvraag. Dit is onderverdeeld in tabbladen voor de diverse onderdelen.

Het scherm kent ook een aantla commando buttons om specifieke opdrachten mee uit te voeren.

De secties zijn

· Algemeen Gegevens gerelateerd aan de interne verwerking van de aanvraag

· Bibliografisch Bibliografische gegevens voor de aanvraag

· Aanvr Bron De oorspronkelijke gegevens van de aanvraag

· Additioneel Eventuele extra ingevoerde informatie

· Klant Klantgegevens (lenersgegevens)

· Aanvrager Specifieke informatie m.b.t. aanvragende bibliotheek

· Leverancier Specifieke informatie m.b.t. leverende bibliotheek

· Bezorging Bezorginformatie

· Kosten Informatie m.b.t. gerelateerde kosten

Wat er precies OP het invulscherm staat is afhankelijk van het soort aanvraag, hoe ver de verwerking van de aanvraag gevorderd is en of het een ISOILL aanvraag is of een handmatig ingevoerde aanvraag.

9 IBL achtergrondverwerking[//]

De IBL daemon wordt opgestart door de Nachtwaker, maar na het opstarten draait hij onafhankelijk van de Nachtwaker. Wanneer hij gedraaid wordt in memory (d.w.z. als reguliere job) is er normaliter ook een “afsluit tijdstip”. Hiermee kan de job automatisch gestopt worden, zodat backups gemaakt kunnen worden e.d. zonder dat er vanuit dit proces wijzigingen in de database zijn.

Vervolgens wordt de job geprogrammeerd om elke ochtend vroeg weer te starten – en dan de hele dag te draaien. De frequentie en stoptijd worden ingesteld onder de Algemene opties van AFO 822.

Er worden twee belangrijke taken uitgevoerd

· “Algemeen onderhoud” voor de module

· Genereren van berichten

Vervolgens draait hij met de ingestelde frequentie om te controleren op

· Inkomende ISOILL berichten

· Inkomende berichten van British Library

· Inkomende berichten van PICA.

Deze taak wordt opgestart via AFO 822.

9.1 Onderhoud[//]

Aanvragen die afgehandeld of geannuleerd zijn blijven tijdelijk zichtbaar bij het lenersrecord (in AFO 431). Het onderhoud verwijdert deze koppelingen zodat er alleen “actieve” anvragen te zien zijn.

Aanvragen die geretourneerd zijn of waarvoor kopieën geleverd zijn, blijven tijdelijk zichtbaar inde “geretourneerd” en “geleverd” overzichtslijsten. Deze worden door de onderhoudsjob verplaats naar het “afgehandeld” overzicht.

9.2 Genreren van berichten[//]

Dit bestaat uit 4 jobs:

· Het genereren van rappels

· Het genereren van berichten voor vervallen aanvragen

· Genereren van bepaalde soorten meldingen

· Genereren van “opvolgmeldingen”

9.3 Rappel – ontvangen exemplaren[//]

Hier zijn twee systeembrede parameters relevant.

a. Toon exemplaren die te laat zijn met melding status na hoeveel dagen te laat?

b. Hoe vaak moet melding status voor te late exemplaren ververst worden?

Alle exemplaren die op de vervaldatum nog niet zijn ingeleverd (plus de parameter onder a) worden getoond in de Meldingen lijst. Parameter a kan negatief zijn, in dat geval worden exemplaren al getoond VOORDAT Ze te laat zijn.

Zulke aanvragen kunnen handmatig uit de meldingenlijst gehaald worden (door aan te geven dat er iets mee gedaan wordt), maar ze verschijnen periodiek opnieuw gebaseerd op parameter b. Dus als ze bijvoorbeeld na een week nog steeds niet ingeleverd zijn wordt er een herinnering gegenereerd.

Daarnaast worden ISOILL aanvragen waarvoor een automatische “te laat” waarschuwing is ontvangen ook in de Meldingenlijst getoond.

De voornaamste reden dat een exemplaar te laat is, zal natuurlijk zijn dat de klant het niet ingeleverd heeft. Rappels hiervoor worden via het reguliere mechanisme van de uitleenmodule aan de lener gestuurd.

9.4 Rappels – geleverde exemplaren[//]

Het genereren van rappels voor aanvragende bibliotheken gebeurt op basis van individuele leverancier. Als deze niet gespecificeerd zijn wordt er gekeken naar de default voor de IBL afdeling in combinatie met de bibliotheek.

Net als voor ontvangen exemplaren is het mogelijk te late geleverde aanvragen in de Meldingenlijst te tonen na een bepaald aantal dagen (mag ook negatief zijn).

Er kunnen tot maximaal twee rappels automatisch gestuurd worden, afhankelijk van de interval in de parameters. Het is mogelijk kortere periodes te definiëren voor teruggevorderde exemplaren.

Exemplaren kunnen ook gemarkeerd worden als “veel te laat”, waardoor ze opnieuw in de Meldingenlijst verschijnen en ook apart getoond worden in het overzicht van alle aanvragen.

Voor elk type bericht wordt een output formaat gedefinieerd. Dat kan zijn voor ISOILL, e-mail, of Print. Dit bepaalt hoe de rappels verstuurd worden. Normaliter altijd ISOILL voor ISOILL bibliotheken, maar de bibliotheek kan ook bepalen dat een bericht apart per post of e-mail verstuurd moet worden.
Als ISOILL of e-mail zijn gedefinieerd en dit is niet mogelijk (geen ISOILL aanvraag of geen e-mail adres) dan wordt het beircht geprint.

Het op basis van deze parameters markeren als ‘te laat' wordt op de gebruikelijke wijze gedaan door de Nachtwaker.

10 Verwerking van ‘vervallen' berichten[//]

Aanvragen kunnen in twee gevallen ‘vervallen':

· Wanneer een expliciete vervaldatum of ‘gewenst voor' datum is verstreken

· Wanneer er een voorwaarde is gesteld die voor een bepaalde datum een antwoord vereist

Dit wordt voor beide gevallen apart toegelicht, uitgesplitst naar inkomende an uitgaande aanvragen.

10.1 Inkomende aanvragen[//]

Vervaldatum

Wanneer er een vervaldatum of ‘gewenst voor' datum is ingesteld (of welke de eerste van beiden is) dan wordt er een ‘vervallen' bericht gegenereerd. Dit wordt verstuurd via het ISOILL mechanisme (wanneer dat mechanisme gebruikt werd voor de aanvraag) of er wordt een brief aangemaakt (die gedrukt of per e-mail verzonden kan worden), wanneer er een lay-out is gedefinieerd voor de berichtenset van de aanvragende bibliotheek.

Dit geldt alleen voor aanvragen met een status “Uitstaand”, “In behandeling” of “Met voorwaarden”. Als een exemplaar eenmaal geleverd is, is de vervaldatum uiteraard niet meer relevant.

Voorwaarden

Wanneer een aanvraag de status “Met voorwaarden” heeft, betekent dit dat de lokale bibliotheek voorwaarden heeft gesteld voor het vervullen van de aanvraag. Het is mogelijk hierbioj een datum op te geven voor wanneer de aanvragende bibliotheek moet reageren. Als deze verstreken is wordt er een bericht gestuurd (via ISOILL of brief/e-mail). Er is een aparte lay-out beschikbaar, om dit bericht te onderscheiden van het reguliere vervalbericht.

Zodra een inkomende aanvraag vervallen is, wordt deze verplaatst naar de sectie “Geheel afgewezen” en is de transactie beëindigd.

Meldingen

The is mogelijk een parameter in te stellen voor de afdeling op basis waarvan aanvragen die op het punt staan te vervallen in de Meldingen lijst verschijnen. Dit biedt de IBL afdeling de mogelijkheid nog stappen te ondernemen om de aanvraag af te handelen.

10.2 Uitgaande aanvragen[//]

Vervaldatum

Voor uitgaande aanvragen wordt geen automatisch ISOILL bericht verstuurd, de aanname is dat de reagerende bibliotheek een vervalbericht aanmaakt. Daarnaast kan hierdoor de aanvraag beëindigd worden bij de huidige bibliotheek, maar kan het nodig zijn de aanvraag door te sturen naar een andere bibliotheek.

In dat geval verschijnt de aanvraag in de Meldingen lijst als een vervallen melding, maar dit heeft geen invloed op de algehele status van de aanvraag. De aanvraag kan geselecteerd worden uit de lijst om handmatig een annuleringsbericht te sturen ana de (niet)leverende bibliotheek. Het annuleringsproces biedt de mogelijkheid om de aanvraag door te sturen.

Antwoord voorwaarden

In dit geval wacht de leverende bibliotheek op een reactie van de IBL afdeling. Als er geen antwoord wordt gegeven, zal de reagerende bibliotheek vermoedelijk de aanvraag beëindigen.

Het systeem toont de aanvraag derhalve weer in de Meldingen lijst voor een antwoord op voorwaarden net voor de datum voor beantwoording (op basis van een parameter voor de afdeling). Als er geen actie wordt ondernomen en de vervaldatum voor beantwoording is bereikt, dan wordt de aanvraag verwerkt volgens de normale behandeling van vervallen aanvragen.

11 WebOpac overwegingen[//]

Er zijn diverse aspecten van IBL gerelateerd aan de WebOpac. Dit zijn:

· Het tonen van IBL aanvragen voor een lener

· De definitie van een template voor het invoeren van aanvragen

· Mogelijkheid voor elektronische handtekeningen en copyright aspecten

· Tonen vaan aanvragen voor aanvragende en leverende bibliotheken

11.1 Tonen van IBL aanvragen[//]

Een optie in de Gebruikersactiviteiten van de Preferences biedt de mogelijkheid leners hun IBL aanvragen te laten bekijken.

Aanvragen worden als volgt getoond:

De bibliotheek bepaalt welke opties aangeboden worden aan de gebruiker.

Deze opties worden aangeboden als commando butttons onder de aanvraag – bijvoorbeeld:

Met de “dagen te tonen” parameter kan worden aangegeven dat bijvoorbeeld geannuleerde aanvragen nog een paar dagen zichtbaar blijven voor de lener. Na een aantal weken is dat echter niet meer zinvol.

11.2 Invoeren van een aanvraag[//]

Het is mogelijk bepaalde lenerscategorieën toe te staan zelf aanvragen in te voeren. Invoer bestaat uit drie hoofdstappen:

· Bepalen of het om een uitleenexemplaar of een kopie gaat

· Invoeren van de bibliografische gegevens

· Opgave van specifieke wensen voor het verwerken van de aanvraag

Elk van deze stappen kan worden geconfigureerd per WebOpac profiel EN per lenerscategorie. Er kunnen bijvoorbeeld simpele definities gemaakt worden voor studenten en meer complexe opties aangeboden worden aan universiteitsmedewerkers die het systeem veevlvuldig gebruiken.

11.3 Setup voor display[//]

Allereerst dienen één of meer templates te worden gedefinieerd om te bepalen welke velden aangeboden worden aan de gebruiker. Tevens dienen er “profielen” gedefinieerd te worden, die bepalen wat de aangeboden opties voor verdere verwerking zijn.

Vervolgens kunnen templates aan een specifiek Web profiel gekoppeld worden en aan een lenerscategorie.

Het invoerscherm voor bibliografische gegevens bestaat uit diverse secties:

· In de eerste sectie kunt u enige inleidende tekst invoeren – bedoeld om de gebruiker te informeren over de procedure voor invoeren van bibliografische gegevens

· In de tweede sectie wordt bepaald welke velden verplicht zijn

· In de derde sectie wordt bepaald welke velden de gebruiker aangeboden worden om in te vullen

11.4 Verwerkingsprofielen[//]

Een verwerkingsprofiel bepaalt welke opties er aan de gebruiker aangeboden worden – mogen ze prioriteit instellen, de kosten aan een budget doorbelasten e.d.

De verwerkingsprofielen bestaan uit meerdere secties:

· Inleiding

· Informatie over de afdeling

· Contact informatie

· Levering

· Diversen

· Kostenberekening

Deze zijn niet allemaal nodig en elke sectie biedt diverse opties. Deze zijn bedoeld om de uiteenlopende methodes en beleidsvormen in bibliotheken te ondersteunen.

11.5 Voorbeelden[//]

Hieronder staan enige voorbeelden van invoeren en tonen van aanvragen in de WebOpac.

11.5.1 Een aanvraag invoeren[//]

Eerste scherm

Hier wordt gevraagd of het om een uitleenexemplaar of kopie gaat.

11.5.2 Tonen van aanvragen aan bibliotheken[//]

De bibbliotheek kan toestaan dat aanvragende bibliotheken hun aanvragen in het lokale systeem bekijken. Aangezien er een “lenersrecord” bestaat voor de aanvragende bibliotheek, kunnen de bijbehorende aanvragen getoond worden.

De presentatie is vergelijkbaar met die voor reguliere leners, maar de verwoording en display kunnen aan de situatie aangepast worden.

12 Uitlenen van ontvangen materiaal[//]

Een exemplaar wordt uitgeleend op basis van de reguliere uitleenregels. Maar het systeem zorgt er wel voor dat de vervladatum kleiner is dan de vervaldatum behorend bij de levering van het aangevraagde materiaal.

13 Document leverantie[//]

De module voor interbibliothecair leenverkeer kan ook gebruikt worden voor ondersteuning van het document leverantie proces. Dit proces valt ergens tussen het beheer van inkomende en uitgaande aanvragen. Document leverantie gaat om het leveren van bibliotheekmateriaal aan externe gebruikers – vaak organisaties, bijvoorbeeld wanneer de bibliotheek materiaal levert aan een advocatenkantoor.

Dit wordt vaak afgehandeld door een IBL afdeling en dus valt het binnen de reguliere beheerfuncties van interbibliothecair leenverkeer.

Het is vergelijkbaar met een inkomende aanvraag

· De aanvraag is voor levering van uitleenexemplaar of kopie van een werk of artikel dat in bezit is van de bibliotheek.

· Het materiaal moet per post of andere bezorgdienst verzonden worden, of er moet een elektronische kopie beschikbaar gesteld worden (bijv. van een tijdschriftartikel).

· Het materiaal wordt op dezelfde wijze geretourneerd, d.w.z. de externe gebruiker komt niet persoonlijk naar de bibliotheek om het weer in te leveren.

· Betaling voor de aanvraag geschiedt doorgaans per factuur, extern vanuit het centrale uitleensysteem

Het is vergelijkbaar met een uitgaande aanvraag

· Er wordt geleverd aan een lid van de bibliotheek

Hoewel een reguliere uitlening van het werk aan de lener aan de basisvoorwaarden voldoet, is dit niet bruikbaar voor het leveren van een kopie. Er is ook geen mechanisme binnen de traditionele uitleenmodule om alle details van een aanvraag op te slaan, het feit dat het om een kopie gaat e.d.

13.1 Paremeters voor document leverantie[//]

Er is een aparte parameter in AFO 822 – Algemene opties – Algemene systeeminstellingen, die bepaalt of document leverantie in gebruik is.

Aanvragen kunnen als document leverantie aanvraag worden ingediend door personeel (zie hieronder). Maar het kan ook door de leners zelf gedaan worden via de WebOpac.

13.2 Vanuit de WebOpac[//]

Als deze optie in gebruik is, verschijnt de betreffende button op het volledig record scerm:

Als de lener geen teostemming heeft voro dergelijke aanvragen, verschijnt er een melding.

In andere gevallen verloopt het verdere proces gelijk aan dat voor een reguliere IBL aanvraag. In de Preferences is een aparte sectie voor het instellen van parameters met betrekking tot Document leverantie – er kunenn dus andere templates en verwerkingsprofielen aangeboden worden.

Op het bibliografische invoerscherm worden de gegevens overgenomen uit het geselecteerde record, maar hier kunnen extra gegevens aan toegevoegd worden zoals bijvoorbeeld titel en pagina's van een bepaald te kopiëren artikel e.d.

13.3 Online functies[//]

Leners kunnen document leverantie aanvragen plaatsen via de WebOpac (afhankelijk van hiervoor beschreven parameters). Zulke aanvragen verschijnen in de sectie “Inkomende aanvragen” van AFO 821, aangezien ze het meest gemeen hebben met reguliere inkomende aanvragen. (In de meeste gevallen kan de aanvrager beschouwd worden als een externe bibliotheek.)

De getoonde aanvraag is vrijwel identiek aan een inkomende aanvraag, maar het Tabblad Aanvrager is vervangen door het Tabblad Klant van een uitgaande aanvraag.

Dit is vrijwel identiek aan een uitgaande aanvraag, alleen staan sommige onderdelen die normaliter bij de aanvragende bibliotheek staan nu op dit tabblad – met name Service type en Service niveau.

13.3.1 Toevoegen van document leverantie aanvraag binnen personeels interface[//]

Bij het invoeren van een nieuwe aanvraag, kan deze gewijzigd worden in een document leverantie aanvraag door het Wijzigen commando te gebruiken. Dit vraagt om bevestiging.

Dit kan alleen worden gedaan bij de initiële invoer van de aanvraag, daarna is een dergelijke wijziging NIET meer mogelijk.

13.3.2 Een uitgaande aanvraag wijzigen in een document leverantie aanvraag[//]

Als een uitgaande aanvraag is ingevoerd – bijvoorbeeld via de WebOpac, dan kan blijken dat deze is voor materiaal dat de bibliotheek zelf in bezit heeft.

Als hierboven beschreven is het mogelijk de aanvraag dan om te zetten in een reservering. Maar voor de toegestane lenerscategorieën kan het OOK worden omgezet in een document leverantie aanvraag.

In feite gaat de verwerking dan verder alsof het een uitgaande aanvraag betreft, d.w.z. het is bestemd VOOR een lener van de bibliotheek. Maat het kan gewijzigd worden in een document leverantie aanvraag, hetgeen van invloed is op de verder beschikbare opties.

13.3.3 Online verwerking[//]

De opties die beschikbaar zijn voor document leverantie aanvragen zijn vrijwel identiek aan die voor uitgaande aanvragen (alsof het al ontvangen is). Zo wordt de “Ontvangen” optie nooit aangeboden – dit heeft geen zin. Ook de “Retourneren” optie verschijnt nooit – wanneer de lener het exemplaar inlevert rondt dit de aanvraag af.

Ook verschijnen velden zoals het Afleveradres niet voor een leverende bibliotheek, maar worden deze afgeleid van het lenersrecord.

14 Testen van het ISOILL protocol[//]

Met deze functie binnen AFO 821 kan de configuratie van ISOILL getest worden. Tevens kan dit gebruikt worden om berichten heen en terug te sturen, als onderdeel van training in het gebruik van ISOILL binnen het systeem.

Met de test functie kunt u een aanvraag versturen alsmede de daaruit voortvloeiende dialogen , naar een bibliotheek gedefinieerd in uw systeem als “INFOR:TEST”. Het is ook mogelijk om aanvragen te sturen vanaf “INFOR:TEST” naar de IBL afdeling, zodat voor trainingsdoeleinden ook getoond kan worden hoe binnenkomende aanvragen er uitzien.

Zulke aanvragen worden via het volledige protocol gestuurd, d.w.z. uit het systeem (en weer terug naar binnen) via de werkelijke e-mail server. Dit is dus een goede test van het systeem en in het bijzonder of de configuratie in orde is.

Neem a.u.b. contact op met de helpdesk voor meer informatie over het inrichten van een test omgeving.

15 Voorbeeld scenario's[//]

Hieronder staat een voorbeeld hoe IBL aanvragen zouden kunnen worden opgezet voor een bibliotheek. Dit gebeurt op basis van vragen met daarbij de antwoorden die het gewenste resultaat geven. Er worden aparte voorbeelden gegeven voor inkomende en uitgaande aanvragen.